At the moment, the host.cpu attributes are about CPUs attached to the host, but I do like the idea of all of these just being under cpu rather than having cpu and host.cpu.

I'll tag in @jsuereth and @dmitryax to answer this question from the entities perspective. host.cpu attributes are not identifying for the host, so they'd probably be considered descriptive attributes. Would it be okay for the host entity to have descriptive attributes that came from a different root namespace, or is it important that any attributes on an entity (even descriptive ones) share a root namespace?

I was actually think about doing that but decided against it as hopefully entity relationships will help that scenario. What about if a message was added on the cpu.* namespace stating something similar to geo in relation to nesting it.

I would like to eventually see the scenario where both a device & the host could have cpu objects especially in virtualised environments which is where the cpu entity would come in hence difficult to put it at the root.

So I have been thinking about this some more especially when trying to improve the brief on the page. While also thinking about how a consistent experience can be offered to users of otel and avoid duplication.

What your thought about moving host.cpu* & cpu.* attributes to be in the hw.cpu.* namespace while also taking advantage of #2417 to avoid duplication? I note cpu is already defined as a value for hw.type.

This would mean that the hardware namespace is where all fixed hardware properties are described.

If you are on board @braydonk / @rogercoll I can make those changes tomorrow.

I think that even this attribute is still not used in system or k8s metrics, it could potentially be. That would be the same case as cpu.mode.

What your thought about moving host.cpu* & cpu.* attributes to be in the hw.cpu.* namespace while also taking advantage of #2417 to avoid duplication? I note cpu is already defined as a value for hw.type.

Although the cpu hw.type is already defined, I find the hw. namespace for cpu attributes redundant. hw. implies a meaningful distinction between hardware and software representations of architecture, but in practice, cpu.arch reflects the effective architecture seen by the process/pod/host —whether real, virtualized, or emulated—making the prefix unnecessary. (not a strong opinion though)

Agree we have a couple of scenarios for using the value of host.arch And it could be used more.

I think it would be beneficial to have 2 distinct attributes:

• hw.cpu.arch/hw.processor.arch to describe what sw is running. It would be great to distinguish between physical and virtual hw but that is seperate issue
• app.arch to describe the architecture it has been built for

Ideally eventually we could use a shared enum between them.

@braydonk - Can you get the @open-telemetry/semconv-system-approvers group to make a decision on this here?
Regarding cpu vs host.cpu namespace, according to our new namespacing rules, cpu is reaosnably unique and this could live in cpu. I defer to System semconv SIG for decision on what they want here.

Don't forget we also have the hw.cpu.* namespace.